Engineering a Programming Language: The Type and Class System of Sather

ion de ned by that type. With multi-methods code does not naturally belong to a particular type. Sather deals with multi-method situations by using \typecase" statements. These appear in the body of a routine which dispatches on the rst argument type and may explicitly dispatch on the second argument type. Unlike a simple \case" statement applied to the type, a \typecase" statement can branch on abstract types. This means they can be used in the same situations that multi-methods would be helpful. This approach also makes the performance consequences of a multi-method organization explicit rather than hiding it behind a complex language construct. Sather routines can also be called directly. A direct call is equivalent to dispatching the routine call on an unbound variable of concrete type (self = void). Direct-called routines are Sather's version of plain procedures in Pascal, class methods in Smalltalk, and static member functions in C++. 2.8 Parameterized Classes Sather allows the de nition of a family of classes parameterized by types. This is a similar mechanism to the generic packages of Ada [28] and templates in the newer versions of C++. Sather type parameters have associated type constraints. The values speci ed for the type parameters are required to be subtypes of these constraint types. The supertyping feature introduced in Section 2.1 is quite useful for de ning such constraints. A constraint type representing an arbitrary union of types can be introduced by forming an appropriate supertype. A second form of genericity in Sather is related to the typing of arguments and return values in inherited code. Sather allows such types to be declared as SAME, similar to Ei el's like-current. If a class A inherits code which refers to the type SAME, it behaves as if the type were replaced by A. For a subclass to be also a subtype, however, this replacement has to follow the subtyping rules stated in Section 2.1. This is very di erent from Ei el's like-current, where a subclass formed in this way is automatically considered a subtype, even though it might well have introduced a conformance con ict. 2.9 Reference and Value Classes Sather distinguishes between reference, value, and bound objects. Most user-de ned objects are reference objects. These are passed by reference as routine arguments and may be aliased. The fundamental types representing boolean values, integers, characters, oating point values, etc. are called value objects. These are always passed by value and it is not possible to alias them (i.e. to reference the same object under two names). More pure object-oriented languages such as Smalltalk and Self try to unify these notions. Languages that only operate over values are typically called functional languages, and operations de ned only over value types are side-e ect free and therefore referentially transparent. On the other hand, reference objects are best used to model entities that have an identity plus a current state. The idea of an object identity bound to a modi able state introduces referential opaqueness and allows for side-e ects. Sather distinguishes between these at the level of types. Instances of value types have value semantics: Once created they never change, and there is no such thing as a \reference" to a value object. Reference objects have an identity and the state of a reference object can be modi ed by writing to its attributes. A variable of abstract type can be used to store either value or reference objects. The special properties of value objects make them especially amenable to compiler optimization techniques. Most important, a value object can be copied freely without the possibility of aliasing con icts. Logically, when value objects are passed as arguments, their value is rst copied and then the operation is invoked on the copy (call by value semantics). Of course, the compiler is free to eliminate this copying whenever it can deduce that the invoked operation cannot modify the object. The introduction of separate value and reference classes imposes certain restrictions on subclassing: An abstract class can only be a subclass of other abstract classes; a value class can only be a subclass of abstract classes and other value classes; a reference class can only be a subclass of abstract classes and other reference classes. 6 2.10 Bound Routines A controversial feature of non-functional programming languages are closures or higher-order functions. While expressive and powerful, certain formulations are di cult to implement e ciently. Hence, many non-functional programming languages provide more lightweight but much less powerful facilities. Pascal [12] introduced procedure parameters, but no procedure variables. This allowed implementations to strictly adhere to a stack discipline, but prevented the use of procedures as rst-class values in data structures. In Modula-2 [29] this was changed to allow for procedure variables, but the restriction was added that only global procedures can be assigned. C [13] has function pointers with a similar semantics. While this allows rst-class procedure values, it restricts such procedures to operate on the global state only, while in Pascal it was possible to pass a nested procedure that in turn could operate on the current bindings of local variables of the passing procedure. Sather, as in C, has no nested routines, hence the C / Modula-2 solution would work without any constraints. However, the constraint that routines bound to a variable can only operate on the global state is much weaker than many applications need. For example, to implement a routine which produces the complement of a boolean argument routine or the composition of two argument routines there must be internal state associated with the routine. The Sather solution is to introduce bound routines5 to express higher-order functions and closure-like constructs. The key idea is that the parameters of a routine, including the implicit self, can be bound to objects. The resulting bound routine can then be assigned to a routine variable of the appropriate type. For example, it is possible to take a routine with two integer parameters, bind one of these to an integer value, and then assign the resulting bound routine to a variable that asks for a routine with a single integer parameter. Bound types describe the resulting signature of a bound routine. Conformance is de ned as contravariant conformance of the type signature. 3 Code Inheritance 3.1 The Textual Inclusion Model for Code Inheritance The semantics of code inheritance in Sather is de ned by textual inclusion of the inherited code. So-called \include" clauses are used to incorporate source code from a speci ed class. The choice of the keyword \include" was made to indicate the textual semantics for the inheritance model. References to the type \SAME" in the inherited code represent the type of the inheriting class. Newly de ned features in a class override inherited features with a conforming signature (as de ned in Section 2.1). This approach di ers from that used in Smalltalk and most other object-oriented languages, in which a call conceptually climbs up in the class hierarchy until a corresponding method is found. For most common cases, the two approaches produce identical results. In complex situations, however, the textual inclusion approach seems easier to understand and to reason about. It is sometimes convenient for a new version of a feature to call the old version that it overrides. Smalltalk solves this problem by providing the \super"-call, which bypasses any matching implementations in the object's class and passes the call directly to the superclass. We found that in Sather, this approach would be confusing in certain circumstances. The problem arises when code which makes a super call is itself inherited. The ambiguity for programmers was whether the inherited \super" call refers to the \super" class of the original de ning class or of the inheriting class. To eliminate this problem, Sather replaces the \super"-call approach with a general \renaming" facility in the include clauses which de ne code inheritance. The include clause comes in two forms: one is used to include and possibly rename a single feature from another class and the other includes an entire class but may cause features to be unde ned or renamed. Renaming is shallow, i.e. renaming a ects only the de nition of the speci ed feature but not calls on that feature6. Appendix A.10 includes the syntax of the construct. Figure 3 uses the example of extending a simple unit (neuron) in ICSIM to a unit with back-propagation learning to show how the \super"-call problem is solved in 5Sather also introduces bound iters. 6Thus, renaming or unde ning a feature may break inherited code. If this is the case the compiler signals a \subclassing error" associated with the corresponding include clause. 7 Sather. The routine accumulated input inherited from SIMPLE UNIT is renamed as the private routine: \SIMPLE UNIT accumulated input" in SIMPLE BP UNIT. class SIMPLE_UNIT is ... accumulated_input: REAL is -Compute the dot product of input values * weights input_port.get_outputs_into_vec(input_values); res := input_values.dot_v(weights) end; ... end; class SIMPLE_BP_UNIT is include SIMPLE_UNIT accumulated_input -> private SIMPLE_UNIT_accumulated_input ... ; ... accumulated_input: REAL is -Compute the dot product of weights * inputs + the bias value res := SIMPLE_UNIT_accumulated_input + bias.val end; ... end Figure 3: Using renaming instead of a \super"-call. One may argue that the renaming solution for \super"-calls unnecessarily clutters the name space. Our experience shows that we use this style of programming infrequently, and if we need it we make the renamed version of the old routine private in order not to a ect the external interface of a class. Because every routine has a speci ed name, the approach eliminates any ambiguity in the interpretation of code. As shown in the next section, the renaming approach is also more general than the \super"-call approach. 3.2 Multiple Subclassing and Con ict Resolution Sather supports multiple subclassing (multiple code inheritance) by allowingmultiple include clauses per class. Since more than one of the superclasses may provide a feature with the same signature, multiple subclassing leads to inheritance con icts. Two routines or iters are said to con ict if they have the same name, the same number and types of arguments, and both either have or do not have a return value. Reference [9] describes four ways to cope with inheritance con icts: 1. Disallow con icts: Signal an error in the case of a con ict. 2. Resolve con icts by explicit selection: Require the user to make a selection in case of a con ict. This is Sather's approach, as described below. 3. Form disjoint union of features: Create a separate feature for each con icting feature. This is the approach of C++ where feature names of suband superclasses are in di erent scopes. The user selects between con icting features using the scope resolution operator \::". 4. Form composite union of features: Create one single feature for each con icting feature by algorithmically resolving the con ict. CLOS [1] follows this approach by linearizing the class hierarchy. 1. to 3. are explicit con ict resolution methods, 4. is an implicit method. Cecil [4] takes an intermediate stance between 3. and 4. by imposing only a partial ordering on classes, and requiring any remaining 8 con icts to be resolved explicitly by the programmer. We agree with [25] that CLOS-style linearization of the inheritance graphs may lead to unexpected method lookups, and result in faulty and hard to debug programs. Sather, therefore, adopts an explicit con ict resolution scheme in which the programmer has to explicitly choose in case of con icts. A class may not explicitly de ne two con icting routines or iters. A class may not de ne a routine which con icts with the reader or writer routine of any of its attributes (whether explicitly de ned or included from other classes). If a routine or iter is explicitly de ned in a class, it overrides all con icting routines or iters from included classes. The reader and writer routines of a class's attributes also override any included routines and must not con ict with each other. If an included routine or iter is not overridden, then it must not con ict with another included routine or iter. Renaming or unde ning in include clauses is used to resolve these con icts. Any language which supports code inheritance must deal with the problem of the same code inherited along two di erent paths. Some languages introduce complex mechanisms to deal with this case, but these tend to be confusing to programmers and rarely do exactly what is desired. Sather's solution is implied by the rules given above. Sather does not consider the origin of code and resolves inheritance solely based on the body of the class itself and the bodies of the classes it includes (after their own code inheritance has been resolved). This behaves like the non-virtual inheritance of C++ for diamond-shaped inheritance graphs, i.e. features from a common superclass are included along each edge. This sometimes necessitates explicitly choosing a single version of a routine inherited along multiple paths, but it eliminates complex rules which depend on the structure of the code inheritance graph. Our experience with the Sather libraries is that we use multiple subclassing only rarely. We therefore felt that these special cases were too weak a justi cation to introduce a complex graph-based subclassing scheme or a strategy based on structural equality of feature de nitions. 3.3 Separate Compilation Sather has no explicit notion of structural units comprising multiple classes. The Sather programming environment is intended to manage and maintain the source code of multiple classes. In particular, when compiling a new class it is often required that the Sather compiler has access to the source code (or at least the type interface and dependency information) of all classes referred to by it. For example, the compiler automatically inlines short routines to improve e ciency. There tend to be many short routines in object-oriented programming because a routine which is needed only for the purposes of an abstract interface often just calls another routine. In addition to eliminating an extra routine call, inlining allows much more optimization to be done within a routine with inlined code. On the one hand, compiler-controlled inlining requires that the code to be inlined is available to the compiler and to the compiler's analysis process, i.e. that the source is at hand. On the other hand, inlining introduces hidden dependencies between implementations. For large systems, there are arguments for introducing another level of modularity. In some cases, one doesn't want to require that all source code be available or allow arbitrary dependencies between compiled units. Such large systems are usually composed of subsystems. For a limited subsystem the global analysis is acceptable. For a composed system, however, it should be possible to de ne the subsystems in a way that global analysis is not required. For Sather, it is possible to form subsystems with strict boundaries in terms of compiler analysis. Such a subsystem must be limited by an interface presenting only types, i.e. empty abstract classes, to subtyping clients, and allowing for direct calls to routines (c.f. Section 2.7) de ned by classes within the subsystem. The most prominent mechanism that cannot be allowed to cross subsystems is code inheritance, which of course is a direct consequence of specifying the semantics of code inheritance based upon the actually inherited source text. Also to be excluded from a subsystem's interface are parameterized classes: The current Sather compiler cannot completely check a parameterized class before its parameters actually get speci ed. This defect in the checkability of Sather's parameterized classes is unfortunate and an issue of ongoing research. However, this problem is not speci c to Sather, the same holds for C++, where such errors might be detected as late as at link-time(!), Ei el, and Ada. Possible solutions tend to either restrict the usefulness of parameterized classes, or to introduce a complicated apparatus to specify 9 su ciently strong bounds on the parameters. Explicit support for expressing subsystem boundaries, such as modules [26], might be a useful extension to Sather. In particular, a module construct would help to package helper classes, to explicitly treat subsystem invariants, to reduce the probability of con icts in the global class name space, and allow limitations to be placed and how much of a source needs to be revealed for purposes of compilation. The best form for such a construct is not yet clear, however, and so the current version of Sather will address these issues at the level of the development environment rather than in the language. 4 Foundations The type system described so far needs to be grounded in explicit built-in classes. A class can do no more than de ne attributes of types introduced by itself or other classes, or de ne routines operating over its own or shared attributes, or invoking other operations. What is missing are the foundational entities to start with. Such foundation entities are present in all languages7 in the form of built-in types or operations with prede ned semantics. In Sather, certain prede ned classes serve this purpose. A language that claims to be \general-purpose" also has to be able to express interfaces to the outside world. For example, a Sather program should be able to call non-Sather libraries, including functions of the underlying operating system and graphical user interface. It is not reasonable to expect that a xed set of built-in classes will ever su ce to serve this purpose in full generality. For these purposes Sather has external classes. Prede ned and external classes are described in the next two subsections. 4.1 Built-in Classes Most classes are de ned by explicit code in a Sather program, but there are several classes which are automatically constructed by the compiler. These classes have certain built-in features that may be de ned in an implementation dependent way. In each case, the choices made by the implementation are described by constants which may be accessed by a program. This section provides a short description of some of the most important built-in classes. The complete and detailed semantics and precise interface is speci ed in the Sather class library documentation. $OB is automatically an ancestor of every class. Variables declared by this type may hold any object. BOOL de nes value objects which represent boolean values. CHAR de nes value objects which represent characters. STR de nes reference objects which represent strings. INT de nes value objects which represent machine-dependent integers. The size is implementation dependent. Classes representing xed-sized integers with a di erent number bits may be de ned by inheriting from INT and rede ning the constant \bsize". All the routines work with an arbitrary \bsize". INTINF de nes reference objects which represent in nite precision integers. They support arithmetic operations but do not support bit operations. FLT, FLTD, FLTE, and FLTDE de ne value objects which represent oating point values according to the single, double, extended, and double extended representations de ned by the IEEE-754-1985 standard. ARR{T} is a reference class de ning dynamically-sized arrays of elements of type T. Classes which inherit from this are called array classes. They allocate space for the array and the attribute asize:INT whose value is the number of elements in the array. TYPE de nes the value objects returned by the type routine. 7In theory, the -calculus, e.g. with syntax E ::= x j EE j x:E, is su cient. Such languages tend to have e ciency problems, though! 10 4.2 Interfacing to External Code Sather provides a few special built-in classes to interface to external code, as listed below. Additionally, Sather's external classes can be used to interface with code from other languages. External classes are not classes in the traditional sense. They can neither be instantiated, nor can they be in a subclass or subtype relationship with any other class. It is merely for the sake of uniformity of the language that external routine interfaces are grouped into external \classes". Each external class is typically associated with an object le compiled from a language like C or Fortran. External classes may only contain routines with distinct names (overloading is not allowed in external classes). The external object le must provide a conforming function de nition with the same name as each routine which doesn't have an implementation in the external class. Sather code may call these external routines using a class call expression of the form EXT_CLASS::ext_rout(5). Similarly, the external code may call one of the non-abstract Sather routines8 de ned in the class by using a name consisting of the class name, an underscore, and the routine name (eg. EXT_CLASS_sather_rout). BITS may be inherited by value classes which represent a single eld of data. The descendant may de ne the two constants bsize:INT and balign:INT to specify the size in bits of the object and its alignment requirements. $EXTOB is used to refer to \foreign pointers". These might be used, for example, to hold references to C structures. Such pointers are never followed by Sather and are treated essentially as integers which disallow arithmetic operations. They may be passed to external routines. 5 Conclusions The design of Sather 1.0 involved trading o an interesting set of constraints regarding e ciency, clarity, reusability and safety. We have described several important aspects of the type and class system and compared them with the solutions chosen by other object-oriented languages. These give rise to a language with a unique combination of conceptual clarity, safety and support for high performance. Acknowledgements Many people were involved in the Sather 1.0 design discussions. Jerry Feldman, Ben Gomes, Ari Huttunen, Chu-Cheow Lim, Heinz Schmidt, and David Stoutamire made suggestions which were especially relevant to the topics discussed in this paper. A Syntax of the Sather Class and Type System The following sections give examples of actual Sather code fragments together with the corresponding grammar rules. The grammar rules are presented in a variant of Backus-Naur form. Non-terminal symbols are represented by strings of letters and underscores in italic typeface and begin with a letter. The nonterminal symbol on the lefthand side of a grammar rule is followed by an arrow \ ) " and right-hand side of the rule. The terminal symbols consist of Sather keywords and special symbols and are typeset in the typewriter font. Italic parentheses \(: : :) " are used for grouping, italic square brackets \[: : : ] " enclose optional clauses, vertical bars \: : : j : : : " separate alternatives, italic asterisks \: : :* " follow clauses which may appear zero or more times, and italic plus signs \: : :+ " follow clauses which may appear one or more times. A.1 Class de nition lists class A is ... end; class B is ... end class def list ) [class def] j class def list ; [class def] 8The calling conventions and the layout of objects are described in the implementation manual of individual versions. 11 A.2 Class de nitionsclass A{S,T:=INT,Uvalue class B < $C,$D is ... endabstract class $E > G,H is ... endclass def ) [value j abstract j external] class class name[{ param dec (, param dec)*}] class inheritance is class elt list endparam dec ) ident [< type spec] [:= type spec]class inheritance ) [< type spec (, type spec)*][> type spec (, type spec)*]A.3 Type speci ersA{B,C{$D}}ROUT{A,B,C}:DITER{A,B!,C}type spec ) [class name] [{ type spec list }] jROUT [{ type spec list }] [: type spec] jITER [{ type spec [!] (, type spec [!])*}] [: type spec]type spec list ) type spec (, type spec)*A.4 Featuresclass elt list ) [class elt] j class elt list ; [class elt]class elt ) const def j shared def j attr def j rout def j iter def j include clauseA.5 Constant attribute de nitionsconst r:FLT:=45.6private const a,b,cconst def ) [private] const ident (: type spec := expr j [:= expr] [,ident list])ident list ) ident (, ident)*A.6 Shared attribute de nitionsprivate shared i,j:INTshared s:STR:="name"readonly shared c:CHAR:='x'shared def ) [private j readonly] shared(ident : type spec := expr j ident list : type spec)A.7 Object attribute de nitionsattr a,b,c:INTprivate attr c:CHAR:='a'readonly attr s:STR:="a string"attr def ) [private j readonly] attr(ident : type spec := expr j ident list : type spec)12 A.8 Routine de nitionsa(FLT):FLT pre arg>1.2 post res<4.3 is ... endb is ... endprivate d:INT is ... endc(s1,s2,s3:STR)rout def ) [private] ident [( arg dec (, arg dec)*)] [: type spec] [pre expr] [post expr] [is stmt listend]arg dec ) [ident list :] type specA.9 Iter de nitionselts!(i:INT, x:FLT!):T is ... enditer def ) [private] iter name [( iter arg dec (, iter arg dec)*)] [: type spec][pre expr] [post expr] [isstmt list end]iter name ) ident!iter arg dec ) [ident list :] type spec [!]A.10 include clausesinclude A a:INT->b, c(INT)->, d:FLT->private d;private include D e:STR->readonly f;include A::a(INT)->b;include clause ) include type spec :: elt mod j[private] include type spec [elt mod (, elt mod)*]elt mod ) ident [( type spec list )] [: type spec] ->[[private j readonly] ident]References[1] D. G. Bobrow, L. G. DeMichiel, R. P. Gabriel, S. Keene, G. Kiczales, and D. A. Moon. The commonlisp object system speci cation. Technical Report 88-002R, X3J13, June 1988. Also in special issueof SIGPLAN Notices 23 (Sep. 1988) and Lisp and Symbolic Computation (Jan. 1989).[2] Gilad Bracha and William R. Cook. Mixin-based inheritance. In Proceedings of the Conferenceon Object-Oriented Programming, Systems, and Applications and European Conferance on Object-Oriented Programming (OOPSLA/ECOOP'90), Ottawa, Canada, October 1990. Also in SIGPLANNotices, 25:10, Oct. 1990.[3] Luca Cardelli. Typeful programming. Technical report, DEC Systems Research Center, Palo Alto,CA, May 1989.[4] Craig Chambers. The Cecil language speci cation and rationale. Technical Report 93-03-05,Department of Computer Science, University of Washington, Seattle, WA, March 1993.[5] William R. Cook. A proposal for making ei el type safe. In Proceedings of the Third European Con-ference on Object-Oriented Programming (ECOOP'89), pages 57{70, Nottingham, England, 1989.Cambridge University Press.[6] WilliamR. Cook, Walter L. Hill, and Peter S. Canning. Inheritance is not subtyping. In Proceedingsof the ACM Conference on Principles of Programming Languages (POPL'90), pages 125{135. ACMPress. Addison-Wesley, 1990.13 [7] Mahesh Dodani and Chung-Sin Tsai. ACTS: A type system for object-oriented programming basedon abstract and concrete classes. In Proceedings of the Sixth European Conference on Object-OrientedProgramming (ECOOP'92), pages 309{328, Utrecht, Netherlands, 1992.[8] Margaret A. Ellis and Bjarne Stroustrup. The Annotated C++ Reference Manual. Addison-Wesley,1990.[9] Richard P. Gabriel, Jon L White, and Daniel G. Bobrow. CLOS: Integrating object-oriented andfunctional programming. Communications of the ACM, 34(9):29{38, September 1991.[10] Adele Goldberg and David Robson. Smalltalk-80, The Language and its Implementation. Addison-Wesley, 1985.[11] Norman Hutchinson. Emerald: An Object-Oriented Language for Distributed Programming. PhDthesis, Department of Computer Science and Engineering, University of Washington, Seattle, WA,January 1987.[12] Kathleen Jensen and Niklaus Wirth. PASCAL: User Manual and Report. Springer-Verlag, 2d ed.corr. print edition, 1978.[13] Brian W. Kernighan and Dennis M. Ritchie. The C Programming Language. Prentice-Hall, 1978.[14] B.B. Kristensen, O.L. Madsen, B. Moeller-Pedersen, and Kristen Nygaard. The BETA program-ming language. In B.D. Shriver and P. Wegner, editors, Research Directions in Object-OrientedProgramming. MIT Press, 1987.[15] Chu-Cheow Lim and Andreas Stolcke. Sather language design and performance evaluation. TechnicalReport TR-91-034, International Computer Science Institute, May 1991.[16] Boris Magnusson. Code reuse considered harmful. Journal of Object Oriented Programming, 4(3),November 1991.[17] Bertrand Meyer. Ei el The Language. Prentice-Hall, 1988.[18] Bertrand Meyer. Object-oriented Software Construction. Prentice-Hall, 1988.[19] Hanspeter Mossenbock and Niklaus Wirth. The programming language Oberon-2. Structured Pro-gramming, 12(4), 1991.[20] Stephan Murer, Stephen Omohundro, and Clemens A. Szyperski. Sather iters: Object-orientediteration abstraction. Technical Report TR-92-xxx, International Computer Science Institute, 1993.[21] Greg Nelson, editor. Systems Programming with Modula-3. Prentice Hall, 1991.[22] Stephen Omohundro. Sather provides nonproprietary access to object-oriented programming. Com-puters in Physics, 6(5):444{449, 1992.[23] Martin Reiser and Niklaus Wirth. Programming in Oberon. Steps Beyond Pascal and Modula.Addison-Wesley, 1992.[24] Heinz W. Schmidt and Benedict Gomes. ICSIM: An object-oriented connectionist simulator. Tech-nical Report TR-91-048, International Computer Science Institute, November 1991.[25] Alan Snyder. Encapsulation and Inheritance in object-oriented programming languages. In Pro-ceedings of the First ACM Conference on Object-Oriented Programming, Systems, and Applications(OOPSLA'86), pages 38{45, Portland, OR, November 1986. Also in SIGPLAN Notices, 21:11, Nov.1986.[26] Clemens A. Szyperski. Import is not Inheritance { why we need both: Modules and Classes. In Pro-ceedings of the Sixth European Conference on Object-Oriented Programming (ECOOP'92), Utrecht,The Netherlands, June 1992.14 [27] David Ungar and Randall B. Smith. Self: The power of simplicity. In Proceedings of the Second ACMConference on Object-Oriented Programming, Systems, and Applications (OOPSLA'87), Orlando,FL, October 1987. Also in SIGPLAN Notices, 22:12, Dec. 1987.[28] U.S. Department of Defence. Ada Reference Manual: Proposed Standard Document, July 1980.[29] Niklaus Wirth. Programming in Modula-2. Springer-Verlag, 1982.15